New Star Software Collection/NSS_Collection.iso/3-069 qemm 603/1.ima/QMANFEST/CH7.MAN

Text File | 1991-10-07 | 10.6 KB | 236 lines

Chapter 7

Extended Memory

This chapter gives you information about the extended memory in
your PC and the memory manager supporting this memory.

The original Intel processors, the 8086/8088, are capable of
addressing one megabyte, over one million bytes, of memory. The
memory management facilities in DOS, as described in Chapter 5,
First Meg, assumed this limitation, as do most of the programs
with which you are familiar. In 1984, the first personal
computers with Intel's 80286 processor were produced. The 80286
is capable of addressing 16 megabytes of memory. 1986 saw the
introduction of Intel's 80386 processor with an addressable space
of 4 gigabytes, over 4 billion bytes of memory. All the memory
installed on an 80286 or 80386 PC, except for the first megabyte,
is referred to as extended memory.

From the viewpoint of DOS and DOS programs, this extended memory,
however much you have installed, is essentially non-existent.
With minimal support from the BIOS ROM, utility programs, (in the
form of RAM disks, print spoolers and disk caches), give you some
benefit from this memory. But DOS did not change to support
extended memory; instead OS/2 was created to support 80286
extended memory.

The architecture of both the 80286 and 80386 processor is
radically different from the earlier processors. Compatibility
throughout the family is maintained by the use of modes in which
the newer processor's capabilities are hidden. The mode common to
the entire family is known as real mode. In real mode, all
processors behave the same with respect to the amount of memory
they can address, i.e. the first megabyte. The 80286 and 80386
both support a protected mode in which they can address the
additional memory their designs support. Additionally, the 80386
has a third mode, known as virtual 8086 mode, which is like real
mode, but has some of the characteristics of protected mode,
particularly memory mapping. Until recently, all the programs you
ran or were likely to run, executed in real mode and were limited
to running in and addressing memory in the first megabyte only.

The presence of extended memory, coupled with the lack of DOS
operating system suppport for it, has led to a number of
innovative solutions by several companies to make better use of
your PC's extended memory.

~Subhead~ Extended Memory Managers

 In 1987 Quarterdeck, in its search for ways to minimize the DOS
overhead required to run its multitasking environment, DESQview,
discovered a way to utilize 64K of extended memory as if it were
conventional memory. This freed up memory which could then be
devoted to applications running in DESQview. DESQview utilizes
the 64K through its extended memory manager QEXT.SYS.

 In 1988 Microsoft formally recognized this technique in what is
now known as the Extended Memory Specification (XMS). Microsoft
Windows makes use of this technique in its extended memory
manager, HIMEM.SYS.

~Subhead~ DOS Extenders

 Also in 1987 Phar Lap Software, Rational Systems, AI Architects
and Oracle each developed a way in which DOS-based application
programs could be larger than 640K. The innovation is called a
DOS Extender, a creative solution which gives application
programs access to a large memory address space and allows them
to run in protected mode without the consent, knowledge or
interference of DOS. A DOS Extender is built into the target
application, and therefore, programs must be written to
specifically make use of their services. You will find this
technique used in Paradox 386, Oracle Professional, IBM
Interleaf, and 1-2-3 Release 3 to name a few programs.

In late 1987 Quarterdeck, recognizing the achievement of the DOS
Extender concept, and its importance and relevance in breaking
through the DOS 640K barrier, joined with Phar Lap in outlining a
specification for a cooperative interface which would ensure
compatibility among DOS Extenders, memory managers and DOS
operating environments. The result of this effort was the Virtual
Control Program Interface (VCPI) specification, which specifies
how DOS Extenders, memory managers and operating environments
communicate. Any memory manager or control program that follows
the VCPI specification allows you, the user, to serially and/or
concurrently make the best use of extended memory or expanded
memory, in the manner expected by the applications you are
running.

No longer the white elephant it once was, extended memory is now
being made available to the end user by programs specifically
written to make use of it (through DOS Extenders) as well as
transparently to existing DOS programs by transforming extended
memory into the more generally useful expanded memory (through
QEMM).

~Subhead~ Extended Overview (TO)

 Extended Overview shows you a map of your PC's extended memory
and how it is being used. This screen appears only if your PC has
extended memory installed and functioning at the time you run
Manifest.

 For each area of extended memory that is used or available, the
map reports the area's beginning and ending addresses, and its
size.

 Some programs allocate extended memory from the lowest to the
highest address first, beginning at 1024K. The map indicates this
by indicating Used from the Bottom in its status column. Examples
of programs that do this are PC-DOS 3.XX's, VDISK, and
Quarterdeck's QEXT.

 Other programs allocate extended memory from the top of extended
memory downward. When these programs are present, the map
indicates their status as Used from the Top. Quarterdeck's QEMM
and DOS Extenders allocate memory from the top.

 Remaining, unallocated memory is called Available.

~Subhead~ Please Note

 Hard to Detect Extended Memory Usage: Some programs manage and
utilize extended memory in ways that cannot be detected by
Manifest (FASTDISK.SYS from AST is one). If Manifest cannot
detect such usage, it is likely that other programs will also
fail to detect such extended memory usage. Typically, the only
remedy is to avoid using such a program in conjunction with other
extended memory programs.

~Subhead~ Extended XMS (TM)

 Extended XMS shows information about the XMS driver which is
loaded at system power up (if it is specified in your CONFIG.SYS
file).

 The Extended XMS screen is available only if you have extended
memory, and an XMS driver is installed.

 XMS is an acronym standing for Extended Memory Specification
proposed by Microsoft Corporation. An XMS driver is an extended
memory manager which implements XMS. HIMEM.SYS is Microsoft's
implementation

 Quarterdeck's QEXT, version 2.26, supports XMS. Earlier versions
of QEXT which predated the XMS specification, provide similar
functionality for DESQview. QEMM-386 Version 5.0 fully supports
both QEXT and XMS as subsets of its overall memory management
capabilities.

~Subhead~ XMS Explained

 XMS defines three areas of memory covered by the spec-ification.
Individual XMS drivers may, or may not support all three. These
are: HMA~dash~high memory area, UMB-upper memory blocks, &
EMB~dash~extended memory blocks.

 HMA is a 64K block of memory starting at the one megabyte
boundary (1024K), the beginning of extended memory. Its primary
and most beneficial use is in enabling program code, nominally
restricted to the conventional memory area, to be loaded and
executed in HMA, thus adding 64K to the addressable DOS memory
space.

 UMB refers to extended memory mapped into unused areas above
640K and below the one megabyte boundaries. Like HMA, available
UMB memory increases effective DOS memory when used with QEMM or
QRAM.

 EMB refers to the remaining extended memory available for
allocation as extended memory.

~Subhead~ Key Terms

 Manifest's Extended XMS screen has a few fields that may not be
familar to you. These are defined as follows:

~Item~ XMS Version: the version of the Extended Memory
Specification supported by your XMS driver.

~Item~ Driver Revision: the revision number of the XMS driver.

~Item~ High Memory Area Allocated: indicates if the High Memory
Area (HMA) is being used, or has been allocated. Only one program
at a time can use the HMA. Consequently, the first program to
access the HMA will be the program which gets to use it.

~Item~ A20 Enabled: A20 is a hardware address line which can be
enabled or disabled under program control. The A20 line is
important in the management of extended memory and the HMA.
Programs usually enable the A20 line when using extended memory
and the HMA and disable it otherwise.

~Item~ Handles Available: Each extended memory block (EMB) that
gets allocated gets a handle associated with it. Thus, there must
be an XMS handle available to honor a request for an EMB. Handles
Available shows you the number of unused handles. With QEMM-386
providing XMS support, XMS and expanded memory handles are
essentially equivalent and are flexibly assigned as needed for
either type of memory allocated.

 NOTE: HMA, although called the "high memory area" in the XMS
specification, does not carry the same meaning as the term high
memory used elsewhere thoughout this manual. Elsewhere the phrase
high memory refers to the memory in the first megabyte above
640K.

~Subhead~ Technical Hints

 XMS & QEMM-386: If you are using QEMM-386 Version 5, XMS support
is provided, as well as the conversion of extended memory into
expanded memory. In this case, the available memory shown on
Manifest's Expanded Memory screen is essentially the equivalent
to the available memory shown on Manifest's Extended Memory
screen.

 Programs Which Request All of Extended Memory: Certain programs
using extended memory will request and be allocated all available
EMBs. This will also exhaust expanded memory, since they are
allocated from the same pool of available memory. If you have
applications which do this, and they prevent other programs or
TSRs from obtaining the memory they need, you should check to see
if that application provides some means of limiting the amount of
memory it requests. In DESQview, this limiting capability is
provided by a field in the program's PIF file.

 XMS & Windows: Microsoft Windows 286 Version 2 and some Windows
dependent programs may use the HMA. All XMS memory is allocated
on a first come, first serve basis. Since DESQview may allocate
this memory also, loading a MS Windows program inside of a
DESQview window may cause a warning diagnostic to be issued by
Windows. This will not prevent the program from running. However,
if you want to avoid this message, Windows use of this area is
optional. See your Windows manual to determine how to change this
configuration.